Visual user interface (UI) designers (e.g., Visual Basic or Visual Studio.NET brand designers) regularly employ properties in the design process. Design elements generally have properties such as Name, Text, Size, Color, etc. Some of these properties, such as Size or Location can be easily set with the mouse and do not require keyboard input. Other properties (e.g., Name, Text), however, are updated through a Property Browser interface which requires tedious cycles such as “select component”, “select property”, “set value,” etc. This process is extremely time consuming, repetitive and, therefore, inefficient. For example, on a form with UI elements (often referred to as “controls”), users almost always have to change the “Text” and “Name” property for each one of them. A moderately complex form may contain over one hundred controls—this can be a significant task.
Attempts have been made to streamline the editing of properties. Particularly, some designers have set a default property value on a component directly on the design surface rather than in the property browser. This is much like spreadsheet applications (e.g., Excel brand spreadsheet application) that allow a user to type directly into a cell rather than always using the entry bar at the top of the screen. These attempts, however, have been strictly limited to the Text property of the control. As well, support and/or configuration of these attempts is specified by the control itself. In other words, the control specified as to whether it is supported and, if so, for what property. This control dictated method leads to inconsistent user experience and implementation.
Conventional visual forms designers were built to allow a developer to rapidly create applications. More particularly, they were designed to streamline the design process such that a developer would be able to focus on the most salient aspect of the task at hand, without having to do unnecessary work. The ability to layout components on a form in a visual manner, and then customize those components for the application, is one the key parts of the overarching user scenario for an integrated development environment (IDE). An IDE can refer to a set of programs run from a single UI. For example, programming languages often include a text editor, compiler and debugger, which are all activated and function from a common menu.
A part of the customization required of a developer involves examining and setting properties on the constituent components within the application. Some visual designers support this key task very well, however the overall experience can be made even more streamline by addressing one of the key existing workflow issues: toggling between the workflow editor and the design surface. In other words, much of the user's attention should be concentrated on either the design surface or code editor, but unfortunately, for many tasks, the user must spend some time—or in some cases, a great deal of time—“outside” of these primary views to get their job done.
There can be several different phases of application development that a user goes through when creating an application within an IDE. As well, no two developers are likely to progress through the phases in exactly the same order and manner. Nonetheless, usually at one or more discrete periods in the application development cycle for a given application, developers enter a UI creation mode. The tasks within the UI creation phase can include the initial creation of a form or forms to be used by application UI. Accordingly, initial layout, configuration (e.g., property getting/setting) and code wire-up for components on the form must be addressed.
Also, within this UI creation phase, as well as others, there are two predominant approaches to proceeding with the work required: Single-pass and Multi-pass. The Single-pass approach refers to the situation whereby each control is placed on the form, its key properties (e.g., Name, Text) set, event handlers wired-up, etc. before moving on to the next control. On the other hand, Multi-pass refers to the situation whereby all controls are dropped from the visual designer toolbox onto the form in sequence. A developer then makes another pass through the controls to set one or more key properties (e.g., Name on each control, Text on each control), then makes another pass to wire-up event handlers, and so on.
What is needed is a system and/or methodology to make the design experience consistent for users and flexible enough to handle arbitrary properties in a unified way. Reducing the number of “clicks” is important for optimizing the productivity of developers using visual designers. By simplifying or streamlining repetitive tasks, designers allow developers to concentrate on solving business problems rather than doing menial tasks. Therefore, what is needed is a system and/or methodology to further streamline the multi-pass approach of configuring properties in a visual form designer. More particularly, a substantial need exists for a system and/or methodology to eliminate (or streamline) unnecessary steps (e.g., property edit toggling) in the configuration process.